High availability lightweight directory access protocol service

ABSTRACT

Management of lightweight directory access protocol (LDAP) service may be accomplished through the use of remote mirroring and a unique application program interface (API). Both a primary and a secondary LDAP server are maintained. Any modification to the primary LDAP server is then mirrored on the secondary LDAP server. When a call is attempted on the primary server, if it fails, the call is retried on the secondary LDAP server. The API allows for specialized grammar for commands that permits the system to handle primary (and secondary) LDAP server failure.

FIELD OF THE INVENTION

[0001] The present invention relates to the field of computer science.More particularly, the present invention relates to an end-to-end highavailability Lightweight Directory Access Protocol (LDAP) service.

BACKGROUND OF THE INVENTION

[0002] Directory services for computer networks have been around forseveral years. When the Internet became popular, it was necessary tocreate a way to locate organizations, individuals, and other resourcessuch as files and devices in a network, whether on the Internet or acorporate network. This information may need to be retrieved evenwithout knowing a domain name, Internet Protocol (IP) address, orgeographic location.

[0003] In order to satisfy this need, the major computer softwarecompanies agreed to the Lightweight Directory Access Protocol (LDAP)standard. LDAP is a client-server protocol, wherein an LDAP directorycan be distributed among many servers on a network, then replicated andsynchronized regularly. LDAP aware client programs may ask LDAP seversto look up entries in a variety of ways. LDAP servers index all the datain their entries and filters may be used to select just the person orgroup needed.

[0004] An entry is a collection of attributes that has a name, called adistinguished name (DN). The DN may then be used to unambiguously referto the entry. Each of the entry's attributes has a type and one or morevalues. The types are typically abbreviated strings, like “cn” forcommon name, or “mail” for email address. The values depend on the typeof the corresponding attributes. For example, a mail attribute maycontain “person@company.com”, whereas a jpegphoto attribute may containa photograph in binary JPEG format. Permissions may be set to allow onlycertain people to access the LDAP database, or to keep certain dataprivate.

[0005] In a typical LDAP network, there is a node (computer) designatedas the master. The LDAP server may run on this master node, in whichcase it is called the primary LDAP server. There are then many clientsdispersed on many different nodes interacting with the LDAP server onthe master node through an LDAP Application Program Interface (API).There is also typically another special node called the vice-masternode, which acts as a backup for the master node in case of failure. TheLDAP server on the vice-master node is called the secondary LDAP server.

[0006] When the LDAP server on the master node fails (or the master nodeitself fails and brings the LDAP server down along with it), thevice-master is promoted to be the new master node. The secondary LDAPserver is then promoted to be the primary LDAP server in the network.

[0007] The data managed by the different instances of LDAP servers(primary and secondary) must be consistent. Though different LDAP serverinstances may be acting as the primary LDAP server, a modificationperformed by the primary LDAP server must be immediately available tothe secondary LDAP server, in case the primary LDAP server fails justafter the modification takes place.

[0008] The typical solution to this problem is to configure the primaryand secondary LDAP serves to use a master-master replication if one isavailable. However, the replication in this case is not strong, in thatthe updates on one LDAP server are not guaranteed to be availableimmediately on the other LDAP server.

[0009] What is needed is a solution which guarantees that the updates onthe primary LDAP server are immediately available on the secondary LDAPserver. Additionally, what is needed is a solution which is completelytransparent to clients, meaning any failure of a primary LDAP server andsubsequent transfer to a secondary LDAP server must undetectable to aclient.

BRIEF DESCRIPTION OF THE INVENTION

[0010] Management of lightweight directory access protocol (LDAP)service may be accomplished through the use of remote mirroring and aunique application program interface (API). Both a primary and asecondary LDAP server are maintained. Any modification to the primaryLDAP server is then mirrored on the secondary LDAP server. When a callis attempted on the primary server, if it fails, the call is retried onthe secondary LDAP server. The API allows for specialized grammar forcommands that permits the system to handle primary (and secondary) LDAPserver failure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated into andconstitute a part of this specification, illustrate one or moreembodiments of the present invention and, together with the detaileddescription, serve to explain the principles and implementations of theinvention.

[0012] In the drawings:

[0013]FIG. 1 is a block diagram illustrating local mirroring.

[0014]FIG. 2 is a block diagram illustrating local mirroring using adisk subsystem.

[0015]FIG. 3 is a block diagram illustrating synchronous remotemirroring in accordance with a specific embodiment of the presentinvention.

[0016]FIG. 4 is a block diagram illustrating asynchronous remotemirroring in accordance with a specific embodiment of the presentinvention.

[0017]FIG. 5 is a block diagram illustrating remote mirroring inaccordance with a specific embodiment of the present invention.

[0018]FIG. 6 is a flow diagram illustrating a method for synchronousremote mirroring in accordance with a specific embodiment of the presentinvention.

[0019]FIG. 7 is a flow diagram illustrating a method for asynchronousremote mirroring in accordance with a specific embodiment of the presentinvention.

[0020]FIG. 8 is a flow diagram illustrating a method for managinglightweight directory access protocol (LDAP) service in accordance witha specific embodiment of the present invention.

[0021]FIG. 9 is a block diagram illustrating an apparatus for managinglightweight directory access protocol (LDAP) service in accordance witha specific embodiment of the present invention.

[0022]FIG. 10 is a block diagram illustrating mirroring software inaccordance with a specific embodiment of the present invention.

DETAILED DESCRIPTION

[0023] Embodiments of the present invention are described herein in thecontext of a system of computers, servers, and software. Those ofordinary skill in the art will realize that the following detaileddescription of the present invention is illustrative only and is notintended to be in any way limiting. Other embodiments of the presentinvention will readily suggest themselves to such skilled persons havingthe benefit of this disclosure. Reference will now be made in detail toimplementations of the present invention as illustrated in theaccompanying drawings. The same reference indicators will be usedthroughout the drawings and the following detailed description to referto the same or like parts.

[0024] In the interest of clarity, not all of the routine features ofthe implementations described herein are shown and described. It will,of course, be appreciated that in the development of any such actualimplementation, numerous implementation-specific decisions must be madein order to achieve the developer's specific goals, such as compliancewith application- and business-related constraints, and that thesespecific goals will vary from one implementation to another and from onedeveloper to another. Moreover, it will be appreciated that such adevelopment effort might be complex and time-consuming, but wouldnevertheless be a routine undertaking of engineering for those ofordinary skill in the art having the benefit of this disclosure.

[0025] In accordance with the present invention, the components, processsteps, and/or data structures may be implemented using various types ofoperating systems, computing platforms, computer programs, and/orgeneral purpose machines. In addition, those of ordinary skill in theart will recognize that devices of a less general purpose nature, suchas hardwired devices, field programmable gate arrays (FPGAs),application specific integrated circuits (ASICs), or the like, may alsobe used without departing from the scope and spirit of the inventiveconcepts disclosed herein.

[0026] In a specific embodiment of the present invention, guaranteedimmediate LDAP server data replication is accomplished using remotelymirrored disks. As its name suggests, mirroring involves the immediatebackup of data to another location. Local mirroring has been availablefor many years. In local mirroring, an operating system issues duplicatewrite commands to separate volumes. This is also known as a dual copy.FIG. 1 is a block diagram illustrating local mirroring. In some systems,a disk subsystem is utilized to handle the actual copy command, whichallows replication to be completed more quickly while offloading thehost's processors and buses. Host 100 issues duplicate writes toseparate volumes 102, 104. FIG. 2 is a block diagram illustrating localmirroring using a disk subsystem. Host 200 issues a write command to adisk subsystem 202, which issues duplicate writes to separate volumes204, 206.

[0027] At first glance, remote mirroring may seem to be just anextension of local mirroring over a geographic distance. However, thereare several problems inherent in local mirroring that makes itinadequate for communication with a distant location. First, highperformance input/output channels have short-distance signalingcharacteristics. For example, the SCSI standard is limited to 25-metercable runs. Although SCSI extenders are available, they are mechanicallycumbersome and expensive, especially as the number of remote connectionsincreases. Other standards have been introduced which can improve uponthese limitations, but at this time it is currently not possible toextend the connection more than 100 km. While this may seem like a largedistance, this does not provide the desired protection against regionaldisasters such as earthquakes and hurricanes. A second problem withextending local mirroring is that there may be a lack of a right-of-wayfor the interconnecting cable. While fiberoptic cable exists under manycities, very little of it is obtainable for private use as most of it isoccupied with telecommunications traffic and switches. Lastly, there isa round-trip delay when extending local mirroring. The delay isproportional to distance, and is exacerbated by the use of extenders andcommunications protocol overhead. This results in progressively slowerapplication response times, as the host must wait for the mirror to beupdated before proceeding.

[0028] Thus, remote mirroring is preferred over local mirroring for manyapplications. In remote mirroring two (or more) hosts are utilized forthe same write operation. The mirroring may either be synchronous orasynchronous. In synchronous mirroring, the host writes to the remotesite as part of the I/O command processing. FIG. 3 is a blockdiagram-illustrating synchronous remote mirroring in accordance with aspecific embodiment of the present invention. Host A 300 issues a writeto database 302. Then it issues a request to write to host B 304, whichissues a write to database' 306. However, database 302 waits forconfirmation of the remote write before signaling I/O completion to hostA 300.

[0029]FIG. 4 is a block diagram illustrating asynchronous remotemirroring in accordance with a specific embodiment of the presentinvention. Host A 400 issues a write to database 402, which thenconfirms the write to host A 400. Then host A issues a request to writeto host B 404, which issues a write to database' 406, which then sendsconfirmation back to host A.

[0030] In a specific embodiment of the present invention, logging isutilized to improve disaster recovery. When an outage happens in theprimary LDAP server, the secondary LDAP server will continue to updateduring the outages. When the primary LDAP server is back online, theimages are no longer synchronized. The process of reestablishingmirrored images is called resynchronization. Logging may be utilized toreduce resynchronization time. Changes occurring during the interruptionare logged. Journals and scoreboards (bi-vectors) are two possible waysto accomplish this. Journaled designs capture every new write in arunning log, whereas scoreboards keep track of changed locations.

[0031] In accordance with a specific embodiment of the presentinvention, several types of resynchronization are possible: fallsynchronization, journaled resynchronization, and updateresynchronization from scoreboards. In full synchronization, a completedisk-to-disk copy is made. This is most useful when the target volume isin an unknown state, such as when it is possible that the volume hasbeen completely erased. In journaled synchronization, the accumulatedwrites are played back against the stale image. In updateresynchronization from scoreboards, the scoreboards keep pointer to disklocations that have been modified during the outage. Scoreboards tend tobe much smaller than journals, and thus are advantageous when disk sizeis a concern, but resynchronization can take longer than in journaledsynchronization.

[0032]FIG. 5 is a block diagram illustrating remote mirroring inaccordance with a specific embodiment of the present invention. Thisdiagram provides more detail than FIG. 2 and FIG. 3. Mirroring softwareon the primary LDAP server may include an application 500, a logicalvolume 502, a bitmap 504, as well as an instant image 506, a fast writecache 508, and a volume manager 510. The secondary LDAP server mayinclude a bitmap 512, a logical volume 514, an instant image 516, a fastwrite cache 518, and a volume manager 520.

[0033]FIG. 6 is a flow diagram illustrating a method for synchronousremote mirroring in accordance with a specific embodiment of the presentinvention. At 600, the application issues a write to the file systems orraw device on the primary site. At 602, this write goes into themirroring software later where a bit is set in the bitmap for the datathat is being requested to be written. At 604, the data is written tothe local disk. At 606, the data is received by the mirroring softwareon the secondary site. At 608, a write request is issued by themirroring software on the secondary site. At 610, the data is written tothe disk on the secondary site. At 612, once the write is committed tothe disk on the secondary site, the mirroring software on the secondarysite receives an acknowledgment. At 614, the mirrroring software on thesecondary site sends this acknowledgment to the mirrroring software onthe primary site. At 616, the mirroring software on the primary sitereceives the acknowledgment. At 618, the mirroring software on theprimary site clears the bit in the bitmap. At 620, the mirroringsoftware on the primary site informs the application that the write hasbeen committed.

[0034] In a specific embodiment of the present invention, the remotemirroring traffic is sent using the Internet Protocol (IP). FIG. 7 is aflow diagram illustrating a method for asynchronous remote mirroring inaccordance with a specific embodiment of the present invention. At 700,the application issues a write to the file systems or raw device on theprimary site. At 702, the write goes to the mirroring software layer onthe primary site where a bit is set in the bitmap for the data beingrequested to be written. At 704, the data is written to the local disk.At 706, the mirroring software on the primary site puts the data in aqueue of data that needs to be transferred. At 708, application on theprimary site is notified of the write completion. At 710, data from thequeue is transferred on a FIFO basis from the primary site to thesecondary site. At 712, the mirroring software on the secondary sitereceives the data. At 714, the data is written to the disk on thesecondary site. At 716, once the write has been committed to thesecondary site, the mirroring software on the secondary site sends anacknowledgment to the mirroring software on the primary site.

[0035] In a specific embodiment of the present invention, transparencyto the user may be accomplished using a specialized application programinterface (API). When a master node fails or otherwise is switched, theAPI will attempt to reconnect to the LDAP server on the new master nodeuntil it succeeds or an implementation defined timeout occurs. If itfails to recover after the timeout is generated, an error may bepropagated to the application. The application may then decide how tohandle the error. Additionally, the API will automatically retry thecall that failed when the LDAP server was down.

[0036] In a specific embodiment of the present embodiment, anapplication may use the API by first initializing an LDAP session withthe LDAP server. A handle is then assigned to the session. LDAPoperations may then be performed and results obtained. When theoperations are completed the session may be closed.

[0037] Operations may be performed synchronously. Asynchronous calls maybe performed by using a native LDAP handle rather than a handle asdefined in the present invention. All routines return an indication ofthe outcome of the operation. However, if a request cannot be servicedbecause of LDAP server failure, no server down error is returned.Instead, the operation is retried with the LDAP server on the new masternode. Only if the request still cannot be serviced on the new masternode will a server down error be returned to the application.

[0038] Since the LDAP protocol is a client-server model, certain LDAPoperations are non-idempotent. A non-idempotent operation is one thatcannot be performed multiple times without producing a semanticallydifferent result than when performed once. In LDAP, the add, delete, andrename operations are non-idempotent, and thus present unique challengesin several scenarios. Several scenarios should be examined:

[0039] 1. The LDAP server crashes before receiving a request. There isno problem with this situation because the data is still consistentbetween the master and the vice-master. The client library will try tocontact the server and get an error.

[0040] 2. The LDAP server crashes after accepting a request but beforeprocessing it. In this case the client library would timeout and tryagain. Since the data is not yet modified, the client perspective whenit tries to access the server on the new master node is unchanged.

[0041] 3. The LDAP server crashes after processing the request butbefore replying. In this case, the data is modified but the client doesnot know the result of its operation. Since the data is replicated usingmirrored disks, the modification is visible on the new master node'sLDAP database. If the client retries the same operation again with thenew server, the result of the operation may be unexpected from theclient point of view.

[0042] It is therefore necessary to have well-defined semantics for thenon-idempotent operations so that retrying a failed call can beaccomplished. For the add operation, an entry will be added if it doesnot exist, but rather then returning an entry already exists error if italready exists, it will instead overwrite an existing entry with the newvalues specified and return a success message. Thus, the client is notnotified unnecessarily when the add operation fails. For example, if theprimary LDAP server crashes after processing the add operation butbefore replying, the operation will be retried. Since the entry hasalready been added, however, the add operation cannot add it again.Therefore it is best not to inform the client of an error as the addoperation really didn't fail.

[0043] For the delete operation, an entry will be deleted if it exists,but rather then returning an entry does not exist error if it does notexist, it will simply return a success message. Thus, the client is notnotified unnecessarily when the delete operation fails. For example, ifthe primary LDAP server crashes after processing the delete operationbut before replying, the operation will be retried. Since the entry hasalready been deleted, however, it cannot be deleted again. Therefore itis best not to inform the client of an error as the delete operationreally didn't fail.

[0044] For the rename operation, an entry will be renamed if the newname does not exist, but rather then returning a no such object error ifthe entry with the old name does not exist, it will simply return asuccess message. Thus, the client is not notified unnecessarily when therename operation fails. For example, if the primary LDAP server crashesafter processing the rename operation but before replying, the operationwill be retried. Since the entry has already been rename, however, theold name will not exist. Therefore it is best not to inform the clientof an error as the rename operation really didn't fail.

[0045] In order to prevent errors, in a specific embodiment of thepresent invention, API calls cannot be interrupted by signals. If asignal is received during an API call, the call runs to completion.

[0046] This unique API allows for recovery from a master nodefailover/switchover until the recovery succeeds or a timeout occurs. Italso allows interactions to be completely hidden from the client.Retrying a failed LDAP call in case of a master node failover/switchoveris also possible. Lastly, the API provides the concept of a sharedconnection to the LDAP server to optimize resources.

[0047]FIG. 8 is a flow diagram illustrating a method for managinglightweight directory access protocol (LDAP) service in accordance witha specific embodiment of the present invention. At 800, a primary LDAPserver and a secondary LDAP server are maintained. At 802, amodification is attempted on the primary LDAP server. At 804, it isdetermined if the call to a primary LDAP server failed. If it did, noerror message is generated, but the process continues to 806, where thecall is retried on the secondary LDAP server. Thus, it may includeelements described in FIG. 4. If it did not fail, the modification ismirrored to the secondary LDAP server at 808. This mirroring may includeremote mirroring, where any modification is sent to separate hosts onthe primary LDAP server and the secondary LDAP server. At 810, it isdetermined if the call to the secondary LDAP server failed. If it did,an error is generated at 812. At 814, any modification to the primaryLDAP server or the secondary LDAP server is logged. It may be logged ina journal or in a scoreboard. If not, the process is complete.

[0048]FIG. 9 is a block diagram illustrating an apparatus for managinglightweight directory access protocol (LDAP) service in accordance witha specific embodiment of the present invention. A primary LDAP serverhaving mirroring software 900 may be maintained. Additionally, asecondary LDAP server having mirroring software may also be maintained902. The mirroring software may be remote mirroring software whichincludes a logging mechanism which logs all modification to the primaryLDAP server or the secondary LDAP server. The logging mechanism mayinclude a journal stored in a memory or a scoreboard store in a memoryfor storage of the logs. The mirroring software attempts to mirror anymodifications to the primary LDAP server on the secondary LDAP server. Acall retrier 904 coupled to the primary LDAP server 900 and to thesecondary LDAP server 902 retries a call on the secondary LDAP server ifit fails on the first LDAP server. A server resynchronizer 906 coupledto the primary LDAP server 900 and to the secondary LDAP server 902 mayresynchronize the primary LDAP server 900 with the secondary LDAP server902 once the primary LDAP server 900 comes back online. An errorgenerator 908 coupled to the call retrier 904 may generate an error ifthe retried call to the secondary LDAP server 902 fails. It should benoted that the call retrier 904 includes a non-error generating callretrier 910 to ensure that no error is generated if the initial call tothe primary LDAP server fails. An LDAP session initializer 912 coupledto the primary LDAP server 900 may initialize an LDAP session with theprimary LDAP server 900. An LDAP session assigner 914 coupled to theLDAP session initializer 912 assigns a handle to the LDAP session. Asignal holder 916 coupled to the call retrier 904 may hold a signalreceived during a call to allow the call to run to completion before thesignal is handled.

[0049]FIG. 10 is a block diagram illustrating mirroring software inaccordance with a specific embodiment of the present invention. A datawriter 1000 may issue a write to the primary LDAP server. A datatransferor 1002 coupled to the data writer 1000 and to a bitmap 1004 maytransfer the write into a mirroring software layer where a bit is set inthe bitmap 1004 for data that is being requested to be written. A datareceiver 1006, used on the secondary LDAP server, coupled to the datawriter 1000 may receive data transferred by a data transferor 1002 ofmirroring software on the primary LDAP server and feed it to the datawriter 1000 for writing to the secondary LDAP server. An acknowledgmentsender 1008 coupled to the data writer 1000 may send an acknowledgementfrom the secondary LDAP server to the primary LDAP server. Anacknowledgment receiver 1010 may receive this acknowledgment on theprimary LDAP server and a bitmap clearer 1012 coupled to theacknowledgment receiver 1010 and to the bitmap 1004 may clear the bit inthe bitmap.

[0050] While embodiments and applications of this invention have beenshown and described, it would be apparent to those skilled in the arthaving the benefit of this disclosure that many more modifications thanmentioned above are possible without departing from the inventiveconcepts herein. The invention, therefore, is not to be restrictedexcept in the spirit of the appended claims.

What is claimed is:
 1. A method for managing lightweight directory access protocol (LDAP) service, including: maintaining a primary LDAP server and a secondary LDAP server; mirroring any modification to said primary LDAP server to said secondary LDAP server; and retrying a call on said secondary LDAP server if said call on said primary LDAP server fails.
 2. The method of claim 1, wherein said mirroring includes remote mirroring.
 3. The method of claim 2, wherein said remote mirroring includes sending any modification to separate hosts on said primary LDAP server and said secondary LDAP server.
 4. The method of claim 1, further including logging any modification to said primary LDAP server or said secondary LDAP server.
 5. The method of claim 4, wherein said logging includes logging said modification in a journal.
 6. The method of claim 4, wherein said logging includes logging said modification in a scoreboard.
 7. The method of claim 1, wherein if said call on said primary LDAP server fails the primary LDAP server is offline.
 8. The method of claim 7, further including if said primary LDAP server is offline, resynchronizing said primary LDAP server and said secondary LDAP server when said primary LDAP server is back online
 9. The method of claim 1, further including generating an error if a timeout is reached when said call is retried on said secondary LDAP server.
 10. The method of claim 1, further including initializing an LDAP session with said primary LDAP server through an application program interface (API).
 11. The method of claim 10, further including assigning a handle to said LDAP session.
 12. The method of claim 1, wherein said retrying includes retrying said call on said secondary LDAP server without generating an error in response to said primary LDAP server failure.
 13. The method of claim 1, wherein said call is an add operation having an entry, and if said entry already exists in the LDAP server to which the call is made, said existing entry is overwritten and a success message is generated.
 14. The method of claim 1, wherein said call is a delete operation having an entry, and if said entry does not exist in the LDAP server to which the call is made, a success message is generated.
 15. The method of claim 1, wherein said call is a rename operation having a first entry and a second entry, and if said first entry does not exist in the LDAP server to which the call is made, a success message is generated.
 16. The method of claim 1, wherein if a signal is received during a call, said call runs to completion before said signal is handled.
 17. The method of claim 1, wherein said mirroring includes: issuing a write to said primary LDAP server; transferring said write into a mirroring software layer where a bit is set in a bitmap for data that is being requested to be written; writing said data to said primary LDAP server; receiving said data by mirroring software on said secondary LDAP server; writing said data on said secondary LDAP server; issuing an acknowledgment from said secondary LDAP server to said primary LDAP server; and clearing said bit in said bitmap.
 18. A system for managing lightweight directory access protocol (LDAP) service, including: a primary LDAP server having mirroring software; a secondary LDAP server having mirroring software; and a call retrier coupled to said primary LDAP server and said secondary LDAP server.
 19. The system of claim 18, wherein said mirroring software is remote mirroring software.
 20. The system of claim 19, wherein said remote mirroring software includes a logging mechanism.
 21. The system of claim 20, wherein said logging mechanism includes a journal stored in a memory.
 22. The system of claim 20, wherein said logging mechanism includes a scoreboard stored in a memory.
 23. The system of claim 18, further including a server resynchronizer coupled to said primary LDAP server and said secondary LDAP server.
 24. The system of claim 18, further including an error generator coupled to said call retrier.
 25. The system of claim 18, further including an LDAP session initializer coupled to the primary LDAP server.
 26. The system of claim 25, further including an LDAP session assigner coupled to said LDAP session initializer.
 27. The system of claim 18, wherein said call retrier includes a non-error generating call retrier.
 28. The system of claim 18, further including a signal holder coupled to said call retrier.
 29. The system of claim 18, wherein said mirroring software further includes: a data writer; a bitmap; a data transferor coupled to said data writer and to said bitmap; a data receiver coupled to said data writer; an acknowledgment sender coupled to said data writer; an acknowledgment receiver; and a bitmap clearer coupled to said acknowledgment receiver and to said bitmap.
 30. A system for managing lightweight directory access protocol (LDAP) service, including: means for maintaining a primary LDAP server and a secondary LDAP server; means for mirroring any modification to said primary LDAP server to said secondary LDAP server; and means for retrying a call on said secondary LDAP server if said call on said primary LDAP server fails.
 31. The apparatus of claim 30, wherein said means for mirroring includes means for remote mirroring.
 32. The apparatus of claim 31, wherein said means for remote mirroring includes means for sending any modification to separate hosts on said primary LDAP server and said secondary LDAP server.
 33. The apparatus of claim 30, further including means for logging any modification to said primary LDAP server or said secondary LDAP server.
 34. The apparatus of claim 33, wherein said means for logging includes means for logging said modification in a journal.
 35. The apparatus of claim 33, wherein said means for logging includes means for logging said modification in a scoreboard.
 36. The apparatus of claim 30, wherein if said call on said primary LDAP server fails the primary LDAP server is offline.
 37. The apparatus of claim 36, further including if said primary LDAP server is offline, means for resynchronizing said primary LDAP server and said secondary LDAP server when said primary LDAP server is back online
 38. The apparatus of claim 30, further including means for generating an error if a timeout is reached when said call is retried on said secondary LDAP server.
 39. The apparatus of claim 30, further including means for initializing an LDAP session with said primary LDAP server through an application program interface (API).
 40. The apparatus of claim 39, further including means for assigning a handle to said LDAP session.
 41. The apparatus of claim 30, wherein said means for retrying includes means for retrying said call on said secondary LDAP server without generating an error in response to said primary LDAP server failure.
 42. The apparatus of claim 30, wherein said call is an add operation having an entry, and if said entry already exists in the LDAP server to which the call is made, said existing entry is overwritten and a success message is generated.
 43. The apparatus of claim 30, wherein said call is a delete operation having an entry, and if said entry does not exist in the LDAP server to which the call is made, a success message is generated.
 44. The apparatus of claim 30, wherein said call is a rename operation having a first entry and a second entry, and if said first entry does not exist in the LDAP server to which the call is made, a success message is generated.
 45. The apparatus of claim 30, further including means for, if a signal is received during a call, running said call to completion before said signal is handled.
 46. The apparatus of claim 30, wherein said means for mirroring includes: means for issuing a write to said primary LDAP server; means for transferring said write into a mirroring software layer where a bit is set in a bitmap for data that is being requested to be written; means for write said data to said primary LDAP server; means for receiving said data by mirroring software on said secondary LDAP server; means for writing said data on said secondary LDAP server; means for issuing an acknowledgment from said secondary LDAP server to said primary LDAP server; and means for clearing said bit in said bitmap.
 47. A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for managing lightweight directory access protocol (LDAP) service, the method including: maintaining a primary LDAP server and a secondary LDAP server; mirroring any modification to said primary LDAP server to said secondary LDAP server; and retrying a call on said secondary LDAP server if said call on said primary LDAP server fails. 